\documentclass{article}

%\usepackage[latin1]{inputenc}

% \usepackage[latin1]{inputenc}
% \usepackage[brazil]{babel}
\usepackage[T1]{fontenc}		% fontes PS com acentos
\usepackage[english,brazil]{babel}	% idiomas permitidos
\usepackage[latin1]{inputenc}		% ediÁ„o direta com acentos
% \usepackage{amsmath}
% \usepackage{amsfonts}
% \usepackage{amssymb}

\title{Respostas}
\date{\today} 
 

 
% \def\ie{\textit{i.e.}} 
% \def\eg{\textit{e.g. }}
% \def\wrt{\textit{wrt }}
% \def\A{\hbox{${\cal A}$}}    
% \def\C{\hbox{${\cal C}$}}
% \def\O{\hbox{${\cal O}$}}
% \def\D{\hbox{${\cal D}$}}
% \def\F{\hbox{${\cal F}$}}

\begin{document}

\maketitle

\begin{quotation}\sf\footnotesize
\noindent
1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
no t\'itulo (``A methodology for building reliable service-based applications'') e
em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
\end{quotation}

``Reliability is even more important  in  object-oriented  programming than 
elsewhere. Meyer presents in \cite{Meyer92,MeyerN93} how to reduce bugs by
building software components on the basis of carefully designed contracts.''

Thus, based on this concept, a software component, whether a service or not,
which is designed based on contracts has reduced the amount of bugs, becoming
more reliable. In the specific case of services, which are loosely coupled
components, the specification and verification of these contracts must be
performed by the services' orchestrator, who shall verify the validity and
execution of these contracts.

The concept of \textit{reliability} used in the thesis, is the concept presented
by \textit{Bertrand Meyer} \cite{Meyer92,MeyerN93,Meyer97} in his definition of
\textbf{Design by Contract}.

Bertrand Meyer \cite{Meyer97} gives these definitions, about
\textit{Correctness, Robustness} and \textit{Reliability} :

. \textit{Correctness}: The ability of software products to perform their exact
tasks, as defined by their specification. 

. \textit{Robustness}: The ability of software systems to react appropriately to
abnormal conditions.

. \textit{Reliability}: A concern encompassing correctness and robustness.

As the contracts for service interfaces are designed to ensure the expected
result after the task performed by the service, and that if the contract is
broken, the service does not apply to the application, we try to ensure
the correctness by applying contracts in independent services.      

Likewise with the robustness, after a contract is broken, the specification
describes alternative paths for the user does not notice the error.   

Thus, we can say that the use of design by contract for services in
service-oriented applications can ensure the reliability of these
kind of applications.

\begin{quotation}\sf\footnotesize
\noindent
2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
protocolos de comunica\c c\~ao diferentes de SOAP.   
\end{quotation} 

Although not mentioned, the methodology can be applied to any service approach,
not necessarily Web services. If observed, the $\pi$-PEWS specifications
generated for the examples present not only WSDL. It is possible to use
the methodology even if the used approaches are JSON,
REST, Java RMI, WCF, and so on. As contracts are about functions, the
restrictions described  through the contracts can used for any
approach, not only Web services.

A more detailed discussion of this aspect will be inserted in the new version
of the thesis' manuscript.

\begin{quotation}\sf\footnotesize
\noindent
3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
referidas na literatura como ``service-oriented applications'' e n\~ao
``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
mas esta diferen\c ca \'e significativa.
\end{quotation}

The use of the expression ``\textit{service-based}'' was used as a synonym for
``\textit{service-oriented}''. We understand the need to better match the title,
for ``\textit{service-oriented}'' application. However, we consider it is
unnecessary to remove the word \textit{reliability}, because its concept is
based on the idea of contracts (see answer to question 1).

Thus the title will be updated to: ``\textbf{A Methodology for Building
Reliable Service-Oriented Applications.}''

\begin{quotation}\sf\footnotesize
\noindent
4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
\end{quotation}

See answer to question 1. 
 
\begin{quotation}\sf\footnotesize
\noindent
5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
\end{quotation}

*We will provide a discussion about consistency of models in the final version
of the thesis manuscript.

\begin{quotation}\sf\footnotesize
\noindent
6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
\end{quotation}

We will make an evaluation of the characteristics of the generated
specification. As our final result is a specification of service composition in
PEWS, we will evaluate quantitative data generated (in terms of lines of
specification).

We will evaluate with works that generate specifications for service
composition, such as the approach proposed by Nikola Milanovic
\cite{Milanovic2006} which generates specifications in B.

\begin{quotation}\sf\footnotesize
\noindent
7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
facilita o tratamento destes requisitos.
\end{quotation}
 
Resposta
 
\begin{quotation}\sf\footnotesize
\noindent
8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
que torna a solu\c c\~ao restrita ao universo de Web Services?  
\end{quotation}

See answer to question 2.

\begin{quotation}\sf\footnotesize
\noindent
9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
com prop\'ositos muito distintos. Considere reescrever esta frase.    
\end{quotation}

``\textit{\ldots some proposals specify services and its compositions by adding
behavioral characteristics, such as PEWS[27], BPEL4WS\ldots}''

 
\begin{quotation}\sf\footnotesize
\noindent
10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
SOC: ``MDA [67] is an important approach for the alignment between highlevel
information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
\end{quotation}

Resposta 

\begin{quotation}\sf\footnotesize
\noindent
11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
servi\c co'': ``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
platform (e.g. WSDL, BPEL or PEWS).''    
\end{quotation}

``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
description or specification language (e.g. WSDL, BPEL or PEWS).''

\begin{quotation}\sf\footnotesize
\noindent
12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' Esta frase sugere que o
projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
todas as partes do sistema precisam ser seguras.       
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize 
\noindent
13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
gerados no final?      
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 


Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
e ``Quality Model for Web Services''.
\end{quotation}

Resposta 

\begin{quotation}\sf\footnotesize
\noindent
15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
\end{quotation}

Resposta 
 
\begin{quotation}\sf\footnotesize
\noindent
16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
\end{quotation}

Resposta  
 
\begin{quotation}\sf\footnotesize
\noindent
17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
pode ter tido um impacto muito grande nos resultados retornados.   
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
fala-se em RNFs.   
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
\end{quotation}

Resposta  


\begin{quotation}\sf\footnotesize
\noindent
20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
estas etapas com as etapas tradicionais.       
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
$\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
que s\~ao exclusivos da $\pi$SOD-M.    
\end{quotation}
 
The concepts added by our approach as form to extend SOD-M proposal is
highlighted in our meta-models by dotted lines around the entities. The new
concepts are:

. \textit{$\pi$-UseCase} model: Constraint, Constraint Type, Non-Functional
Requirement, and Non-Functional Attribute.

. \textit{$\pi$-ServiceProcess} model: Contract, Assertion, Assertion Property,
Exceptional Behaviour.

. \textit{$\pi$-ServiceComposition} model: Policy, Rule, Event Type, Variable,  Non-Functional
Requirement. 

. \textit{$\pi$-PEWS} model: There was no definition of the $\pi$-PEWS concepts
in the original SOD-M. Thus, all elements are new. 

The main purpose of adding these elements is the need to better represent the
constraints associated with the services and how these restrictions can be
represented by each meta-model entity. As the restrictions associated with the
services are refined at each iteration, the representation also changes in each
meta-model.    

\begin{quotation}\sf\footnotesize
\noindent
23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
\end{quotation}

Yes, this is true.  

\begin{quotation}\sf\footnotesize
\noindent
24 - DEVISE \'e uma metodologia?  
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
por um ``use case''.
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
NF-Properties e NF-Requirements. 
\end{quotation}

Resposta  

\begin{quotation}\sf\footnotesize
\noindent
28 - N\~ao entendi a frase ``The quality properties at the system level represent
a behaviour that is part of the workflow.''
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.'' A metodologia fornece um
framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
justificar porque a metodologia adota esta separa\c c\~ao.    
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
ela deveria ser bem descrita.      
\end{quotation}

Resposta 

\begin{quotation}\sf\footnotesize
\noindent
32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
vis\~oes.  
\end{quotation} 

The Business and Services views were inherited from SOD-M \cite{CastroMV11}, the
Policy view encompass the elements and concepts necessary to describe constraints for
services. Thus, it was included in the structure of SOD-M the Policy view
as a way to represent these concepts during the application design.   

\begin{quotation}\sf\footnotesize
\noindent
33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
UML por um ester\'otipo.  
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
metamodelos).    
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
``designer'' referido na frase ``The designer must specify\ldots''.      
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
WS-BPEL?   
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
39 - J\'a existia um metamodelo de PEWS?   
\end{quotation}

No. The PEWS meta-model was specified based on its language and its extension (during the PhD
stage in Grenoble), where we added the concepts of contracts.

\begin{quotation}\sf\footnotesize
\noindent
40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
\end{quotation}

All transformations were also described in ATL, but were not included in the
thesis' manuscript. We will insert as an appendix of the
thesis, or as a link address where anyone can download (with the specific
referenc in the text of the thesis).
   
\begin{quotation}\sf\footnotesize
\noindent
41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
\end{quotation}
 
The environmental requirements are the Eclipse Modelling (Galilleo or higher)
and all plugins proposed, \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-SerciveComposition} and \textit{$\pi$-PEWS} editors; and also the
transformation plugins. Because the environment is proposed in the
context of Eclipse, the environmental requirements are also the same needed to
utilize the Eclipse tool.
 
\begin{quotation}\sf\footnotesize  
\noindent
42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
\end{quotation}

Resposta 

\begin{quotation}\sf\footnotesize
\noindent
43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
\end{quotation}

As suggested, we will use the term ``\textbf{\textit{Examples}}'' to the case
studies presented. Likewise, instead of ``\textit{Validation}'', we use
the term ``\textbf{\textit{Evaluation}}'', in Chapter 5, as a way to better represent
what was done.

\begin{quotation}\sf\footnotesize
\noindent
44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
\end{quotation}

Resposta

\begin{quotation}\sf\footnotesize
\noindent
45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
\end{quotation}

The items will be described more detailed in order to make clear what will be
done in \textit{Future Work}.

 
\bibliography{respostas}
\bibliographystyle{plain}

\end{document}
